When reading books, job requirements, software development methodologies, web sites and blogs, project estimates, and all kind of text about information technologies, terms like 'architect' and 'architecture' are abundant. Here are some I found rummaging through some old documents:

• Business architecture
• Functional architecture
• Computer architecture
• Enterprise architecture
• Segment architecture
• Solution architecture
• Hardware architecture
• Information architecture
• Software architecture
• Systems architecture
• Technical architecture
• Data architecture
• JEE, J2EE architecture
• Logical architecture
• Physical architecture
• Process architecture
• ...

In the past I've had some conversations with people having very, clearly defined meanings for certain variants of 'Architect' - mainly consultants from big consulting firms using The One and Only software consulting methodology in exchange for large consultancy fees.

What is clear to me is that the notion of 'architect' is very much dependent on context. That context is often provided by the prevailing methodology, the main interests of groups of people etc. For instance a group of software developers talking about architecture, will probably talk about the large picture of there proposed solution. A group of hardware guys are probably talking about metal boxes and cables and how that can be described in broad brush strokes. Non-technical management will probably be more focused on the functional part of the system.

What does appear to be a constant factor is what is often described as the '30.000 feet' or 'helicopter' view of the system. It implies seeing the overall picture instead of a large bunch of tiny, technical details.

To me - and that's a personal consideration - the most additional business value in an IT context is created by a decent Enterprise Architecture and Software Architecture.

Of course, the next question should be what I understand by these terms.

To me, the essence of an Enterprise Architecture is:

Enterprise Architecture looks at how different components - applications, tools, databases, ... - can work flawlessly, efficiently together.

And the essence of Software Architecture is:

Organizing software components - classes, API's, dependencies, data bindings etc. - in such a way that the result is easy to maintain, reuse, adapt that it works as intended, that it

We could add lots of different, important considerations that are essential to an Enterprise Architecture , but that is not the purpose of this article, I just want to explore the what Architecture means.

Perhaps we can conclude that architecture in general is about organizing Building Blocks in such a way that you obtain something that is and will remain valuable to your business. Or as others have put it "aligned with the business".

Now, all that remains is to think about what is value and which Building Blocks we are pushing around...

If you ever had the luck to read Anti Patterns , they describe in a humorous way, typical problems with patterns named 'Stovepipe Enterprise', 'Vendor Lock-In' and 'Cover Your Assets'